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Introduction to the STD Notes 


Status of this Memo 


This RFC describes a new sub-series of RFCs, called STDs (Standards). 
Distribution of this memo is unlimited. 


1. Introduction 


The STDs are a subseries of notes within the RFC series that are the 
Internet standards. The intent is to identify clearly for the 
Internet community those RFCs which document Internet standards. 


2. The Assignment of STD Numbers 


There is a need to be very clear about which specifications have 
completed the full process of standardization in the Internet. To do 
this an STD number will be assigned to a specification when it 
reaches the Standard maturity level. Note that specifications may be 
either Technical Specifications (TS) or Applicability Statements 
(AS). 


When a specification reaches the final stage of the standardization 
process and the IAB has designated it a standard for the Internet, an 
STD number will be assigned to that specification. 


The existing standards have been assigned STD numbers (see Appendix). 


The standard for a particular protocol will always have the same STD 
number. 


If at some future time a protocol is reworked and a new document 
is produced as the specification of that standard and the new 
specification is designated by the IAB as a standard for the 
Internet, then the new document will be labeled with the same STD 
number (of course, that new document will have a new RFC number). 


Multiple Documents for One Standard: 
A STD number identifies a standard not a document. A document is 
identified by its RFC number. If the specification of a standard 


is spread over several documents they will each carry the same STD 
number. 
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For example, the Domain Name System (DNS) is currently 
specified by the combination of RFCs 1034 and 1035. Both of 
these documents are now labeled STD-13. 


To be completely clear the DNS "Concepts and Facilities" 
document can be referenced as "STD-13/RFC-1034". 


In such cases, whenever possible, the set of documents defining a 
particular standard will cross reference each other. 


One Standard or Multiple Standards: 


One difficult decision is deciding whether a set of documents 


describe one standard or multiple standards. In the Appendix, one 
can see that there are several cases in which one STD applies to 
multiple RFCs (see STDs 5, 13, and 20). There is one case in 


which a family of specifications has multiple STD numbers; that is 
the Telnet Options. 


The general rule is that a separate STD number is used when the 
specification is logically separable. That is, logically 
separable options are assigned distinct STD numbers while 
amendments and non-optional extensions use the same STD number as 
the base specification. 


Multiple Versions or Editions of a Standard: 


It may occur that the documentation of a standard is updated or 
replaced with a new document. In such cases, the same STD number 
will be used to label the standard. No version numbers will be 
attached to STD numbers. There need be no confusion about having 
the up-to-date document about STD-9 since each version of the 
document will have a distinct RFC number (and of course a 
different date). 


The complete identification of a specification and its document is 
the combination of the STD and the RFC. For example, "STD-13/RFC- 
1035" completely identifies the current version of the second part of 
the Domain Name System specification. 


To completely identify all of the DNS standard the citation would 
be "STD-13/RFC-1034/RFC-1035". 


One way to think of this is that an acronym (like TCP) refers to a 
concept, which is called a protocol. An RFC number (like RFC-793) 
indicates the specific version of the protocol specification. An STD 
number (like STD-7) designates the status of the protocol. 
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Why an RFC Subseries ? 


There are several reasons why the STDs are part of the larger RFC 
series of notes. 


The foremost reason is that the distribution mechanisms for RFCs are 
tried and true. Anyone who can get an RFC, can automatically get a 
STD. More important, anyone who knows of the RFC series can easily 
find the STDs. 


Another reason for making STDs part of the RFC series is that the 
maintenance mechanisms for RFCs are already in place. It makes sense 
to maintain similar documents is a similar way. 


Format Rules 


Since the STDs are a part of the RFC series, they must conform to 
"Request for Comments on Request for Comments: Instructions to RFC 
Authors" (RFC-1111) with respect to format. 


1 Status Statement 


Each STD RFC must include on its first page the "Status of this Memo" 
section which contains a paragraph describing the intention of the 
RFC. This section is meant to convey the status approved by the 
Internet Activities Board (IAB). 


.2. Distribution Statement 


Each STD RFC will also include a "distribution statement". As the 
purpose of the STD series is to disseminate information, there is no 
reason for the distribution to be anything other than "unlimited". 


Typically, the distribution statement will simply be the sentence 
"Distribution of this memo is unlimited." appended to the "Status of 
this Memo" section. 


3. Security Considerations 


All STD RFCs must contain a section that discusses the security 
considerations of the procedures that are the main topic of the RFC. 


-4. Author’s Address 


Each STD RFC must have at the very end a section giving the author’s 
address, including the name and postal address, the telephone number, 
and the Internet email address. 
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In the case of multiple authors, each of the authors will be listed. 
In the case of a document produced by a group, the editor of the 
document will be listed and optionally the chair of the group may be 
listed. 


4. The STD Publication 


New documents can only become STD RFCs through an action of the IAB. 
The publication of STDs will be performed by the RFC Editor. 


5. STD Announcements 
New STD RFCs are announced to the RFC distribution list maintained by 
the Network Information Center (NIC). Contact the NIC to be added or 
deleted from this mailing list by sending an email message to RFC- 
REQUEST@NIC.DDN.MIL. 

6. Obtaining STDs 
STD RFCs may be obtained in the same way as any RFC. 
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending 


an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: 
ways_to_get_rfcs". For example: 


To: rfc-info@ISI.EDU 
Subject: getting rfcs 


help: ways_to_get_rfcs 


The current standards are listed in the "IAB Official Protocol 
Standards" (which is STD-1), whose current edition is RFC-1280. 


Security Considerations 

Security issues are not discussed in this memo. 
Author’s Address 

Jon Postel 

USC/Information Sciences Institute 

4676 Admiralty Way 

Marina del Rey, CA 90292 


Phone: 310-822-1511 
Fax: 310-823-6714 


Email: Postel@ISI.EDU 
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APPENDIX -- The Grandfathered STDs 

Protocol Name Status RFC STD 
Stec rne IAB Official Protocol Standards Req 1280 I 
aie aie Assigned Numbers Req 1060 2 
Sanaa Host Requirements Req 1122,1123 3 
AERE Gateway Requirements Req 1009 4 
IP Internet Protocol Req 791 5 

as amended by: 

SSacessr IP Subnet Extension Req 950 5 
a i IP Broadcast Datagrams Req 919 5 
Fenn Hn, IP Broadcast Datagrams with Subnets Req 922 5 
ICMP Internet Control Message Protocol Req 792 5 
IGMP Internet Group Multicast Protocol Rec 1112 5 
UDP User Datagram Protocol Rec 768 6 
TCP Transmission Control Protocol Rec 793 F; 
TELNET Telnet Protocol Rec 854,855 8 
FTP File Transfer Protocol Rec 959 9 
SMTP Simple Mail Transfer Protocol Rec 821 10 
MATL Format of Electronic Mail Messages Rec 822 ‘LL. 
CONTENT Content Type Header Field Rec 1049 11 
NTP Network Time Protocol Rec TL19 12 
DOMAIN Domain Name System Rec 1034,1035 13 
DNS-MX Mail Routing and the Domain System Rec 974 14 
SNMP Simple Network Management Protocol Rec 1157 15 
SMI Structure of Management Information Rec 1155 16 
MIB-II Management Information Base-II Rec 1213 Li] 
EGP Exterior Gateway Protocol Rec 904 18 
NETBIOS NetBIOS Service Protocols Ele 1001,1002 19 
ECHO Echo Protocol Rec 862 20 
DISCARD Discard Protocol Ele 863 21 
CHARGEN Character Generator Protocol Ele 864 22 
QUOTE Quote of the Day Protocol Ele 865 23 
USERS Active Users Protocol Ele 866 24 
DAYTIME Daytime Protocol Ele 867 25 
TIME Time Server Protocol Ele 868 26 
Telnet Options Option Status RFC STD 
TOPT-BIN Binary Transmission 0 Rec 856 27 
TOPT-ECHO Echo 1 Rec 857 28 
TOPT-SUPP Suppress Go Ahead 3 Rec 858 29 
TOPT-STAT Status 5 Rec 859 30 
TOPT-TIM Timing Mark 6 Rec 860 3:1 
TOPT-EXTOP Extended-Options-List 255 Rec 861 32 


Internet Activities Board [Page 5] 


